In depth: From Java to Kotlin - the joys of new code

Originally posted on our ‘Base’ Medium account.
In September 2019, Base became Passenger.

At Base, we prefer not to stand still. We’re constantly experimenting and exploring, finding the right tools for the right job. That’s why we got so excited when Google announced official support for Kotlin. We’ve been using it extensively since, finding ways to better support and drive our transport solution Passenger. Find out how, and why, below.

There are few worse sins in the world of technology than standing still and staring down at your feet. The industry innovates fast — those responsible for a product must be aware of what’s coming to prevent either falling behind the pack or plunging down otherwise avoidable pitfalls.

That’s why we keep pace at Base (heh). It’s also why, ever since official Kotlin support was announced at Google IO in 2017, we’ve been looking at ways we can make use of this fantastic new language — particularly so in the codebases of our transport solution Passenger.

What is Kotlin?

Kotlin is a statically typed programming language that runs on the Java virtual machine and also can be compiled to JavaScript source code or use the LLVM compiler infrastructure. It was created by Jetbrains (also the guys who created IntelliJ — the IDE that Android Studio is based on) back in 2011.

Prior to 2017, Kotlin had no official support for Android development. I’ve always tried to steer away from things that are not officially supported, as you just never know where that particular technology or library will go. It could be that the language/library is dead after a few months — months during which you’ve invested hundreds of wasted hours into the code.

Thankfully, Google saw the light and announced official support for Kotlin in 2017, even going so far as to create a foundation with Jetbrains to support the programming language. That meant we could dive right in…

What makes Kotlin so good?

Since Android first became a thing, the primary development language used has been Java. Java is pretty good as the syntax is easy to understand and you can write your code once and deploy to many different environments. This versatility is one of the many reasons why Android has become so successful.

But, as always, there remain drawbacks. For one, Java is a privately owned and patented language by Oracle, who went through a very lengthy and expensive lawsuit with Google over disputes on uses of Java APIs.

Another, more technical drawback with Java is that is an old language, and being an older language means it sometimes lags behind others in adding new features like lambda support.

With Kotlin, you get the best of both worlds. Not only can you write Kotlin alongside your Java code (making it easy to convert existing codebases) but it comes with all the bells and whistles of a modern language, which developers have grown accustomed to with languages such as JavaScript (ES6), Swift, Rust, Go and so on.

Some other useful features of Kotlin include…

…reducing code size.Compared to Java, the code written in Kotlin is at least 40% smaller, just due to the removal of boilerplate code provided in Kotlin, such as automatic getter/setters for variables…

…the Kotlin extensions plugin, which allows us to directly reference views in our layout without having to make direct calls via the framework…

…being able to pass lambdas as variables, which means we no longer have to create “listener” interfaces and anonymous object classes…

…and my favourite feature, the non-nullability and safety of the code. Typically in Java, variables can be null (which means they have no value). This is the number one cause of crashes in probably every app on Google Play. With Kotlin, however, everything is non-null by default, which means things haveto be set, else it just won’t compile (unless its marked as lateinit). This forces the developer to ensure that things that could be null are properly handled with solutions like the Elvis Operator. This also allows us to do cool things that reduce the number of “if not null” checks, which further reduces boilerplate and amount of code written. All that time adds up to enough time for at least a few more trips down to the pub a year!

How are we utilising Kotlin in our codebase?

The codebase we use for Passenger is pretty big. The software is built on 13 different framework libraries, each packed with countless features. It’s not realistic for any development company (unless they have unlimited time and resources) to immediately re-write their entire codebase into a new language, However, it is very possible to slowly convert existing code, alongside writing new code in the language — which is exactly what we’re doing.

Many iOS developers know the pain of converting their old Objective-C code into Swift; the interoperability was OK but not perfect. With Kotlin, there is very little (that I have experienced at least) pain with interoperability, which makes writing new features super-easy to do. So far, every recent feature in Passenger, such as the new Disruption module, the new Live Buses feature, and the new Favourites section, have all been written in Kotlin, while bug fixes for existing features have remained in Java.

Eventually, the plan is to have re-written all the features and code into Kotlin, but naturally that will take time. As ever, it makes sense to start small and build up the refactors as and when it is appropriate without disrupting the user experience and final quality of the product we release.

But that’s what we do at Base. We follow new technologies, we adopt them where it makes sense, and we work out to use them in a way that reaps great benefits with minimum disruption. That sense of exploration and experimentation is part and parcel of what we do — and why we love it.